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PRIMARY ACCESS CONTROL IN LARGE-SCALE 
TIME-SHARED DECISION SYSTEMS* 


Abstract 


The computer differs from other tools in that it presently 
“does not provide its users with a working environment transparent 
to their desires; in particular, current computer systems do not 
support adequate mechanisms for controlled sharing of sensitive 
information. 


Four primary dimensions of the access control problem are 
identified. They are: 1) the physical level at which to apply 
control; 2) the fineness of distinction applied to the term "ac- 
cess", 3) the meaning of the term "usér identification", and 4) the 
degree of sophistication employed in automatically assigning restric- 
tions to new data files. 


Within the context of MacAIMS, the Project MAC Advanced Inter- 
active Management System, the design of an access control system is 
presented which takes positions along these four dimensions appro- 
priate for controlling access in a Management Decision System. Sup- 
port is provided for constraints specified as general logical restric- 
tions based on 1) the characteristics of the entity requesting access, 
2) the content of the sensitive data item, 3) the context in which the 
sensitive item appears, 4) proper completion of an interactive proce- 
dure, and 5) combinations of any of these. The access levels which 
may be specified are based on the logical (not the physical) nature 
of the interaction which the user requests. 


The system presented here is an interim system in that it does 
not solve all of the access control problems of MacAIMS. Among the 
unsolved problems is the problem of Truth -- in a data management 
system which provides a powerful set of operators, it is easy to 
create false information in very subtle ways. Another problem is 
that of conflicts of privacy. Solutions to these problems must be 
found before the access control scheme will be complete. 


*This report reproduces a thesis of the same title submitted to the 
Alfred P. Sloan School of Management, Massachusetts Institute of 
Technology, in partial fulfillment of the requirements for the degree 
of Master of Science in Management, May 1971. 
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1. INTRODUCTION 


1.1. Privacy 

Constder for a moment the stone-age axe. Like all 
the tools which man designed both earlfer and later in his 
history, the axe serves as an amplifier of his abilities -- 
in this case, an amplifier of his ability to strike. 
Perhaps the second most important characteristic of the axe 
is that it is Indifferent with regard to what it strikes; 
it may be used equally well on either a log or another man's 
head. The axe provides a working environment which Is 
amoral by Itself, but which possesses the ability to reflect 
the morals of its user. 

Like the axe, the computer [s a_ tool: it 
amplifies man's ability to process and disseminate 
Informatton. Computers are potentially more dangerous than 
axes by virtue of the magnitude of their amplification, but 
this difference is not basic. It is the second referent 
which distinguishes the computer from the axe _ in an 
essential way -- In spite of the fact that considerable 
progress has been made In recent years, the environment 


provided by most present-day computer facilities lacks the 
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ability to adequately mirror wishes of the users. It is to 
a portion of this problem that the present work is 
addressed. 

There is today no widespread public agreement 
regarding what the issues surrounding the privacy problem 
really are. In the absence of such a concensus, imposing a 
specific set of standards upon a computer system (if such an 
imposition were possible), would be almost as bad as no 
control at all. What is needed instead is to devise a 
system which is transparent to the wishes of the users -- 
their desires to control the flow of information should be 
exactly expressible within its environment. 

At the outset it is useful to consider briefly a 
few of the more important social issues which are now in the 
public eye. These issues have been discussed elsewhere’ in 
greater detail; the bibliography contains a list of some of 
the better works. 

It is probably safe to say that everyone has an 
intuitive tdea of the meantng of the word "privacy"; it fs 
probably also safe to say that most of those intuitions are 
over-simplistic. At least one definition of privacy has 
been suggested which emphasizes many [Important aspects of 
the problem: in Privacy and Freedom, Professor Alan Westin 
has said 

"Privacy Is the claim of Individuals, groups, or 


Institutlons to determine for themselves when, how, and 
to what extent information about them is communicated 
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to others.... The individual's destre for privacy is 
never absolute, since participation in society is an 
equally powerful desire. Thus each individual Is 
continually engaged in a personal adjustment 
process...in the face of pressures from the curiosity 
of others and from the processes of survelllance that 
every society sets in order to enforce tts social 
norms." 

Thus the privacy deciston is the cholce of an individual In 

trading off his desire to be an individual against his 

desire to participate In soclety. 

From the individual's viewpoint, Dr. Westin 
identifies four primary (and essential) functions of 
privacy: It 1) provides personal autonomy, 2) gives 
opportunity for emotional release, 3) allows self-evaluation 
and introspection, and &) permits the protected and 
privileged transfer of information. As the book's title 
indicates, these functions are very closely related to the 
concept of freedom. But the need for privacy goes even 
beyond such logical considerations -- Dr. Westin suggests 
that privacy may be as much a blologica) necessity for man 
as It Is for other animals. (31) 

The concept of norm-enforcement is inherent In the 
definition of "society". In order to enforce norms, a 
society establishes a variety of Institutions which watch 
over individuals and monitor thetr behavior; thus cumulative 
social pressure places constraints on each citizen's privacy 


deciston. Clearly such norm-enforcement Is essential to the 


preservation of civilization -- we cannot, for example, 
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choose to drive at excessive speeds or to burn down our 
neighbor's house in the name of privacy. In order to 
accomplish such enforcement, collection and processing of 
considerable amounts of information about citizens is 
necessary. A logical framework for viewing the reasons for 
this collection is discussed in (32). 

Perhaps the most important issue of the privacy 
problem, then, is the tradeoff of the individual's needs 
against the society's needs. Unanswered questions’ Include 
the exact costs associated with that tradeoff and the 
identity of the party (or parties) who should make the final 
decision. 

Another extremely important Issue, and one which 
has recelved almost no attention to date, Is that of 
conflicts of privacy. Most, if not all, data which are of 
Interest are the joint property of at least two parties -- 
the person who origtinated the information, and the person 
whom the data concern. Moreover, much Information may be 
the joint property of considerably more than two parties. 
In many cases the privacy rights of these partles conflict. 
For example, a physician would not wish a patient to see his 
own medical record if that record showed he was a_ hopeless 
hypochondriac. A complete solutlon to the privacy problem 
must include mechanisms for the resolution of such 


conflicts. 


1.2. The Computer and Privacy 
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The essence of the solution to the privacy 
problem, then, is providing the ability to control the flow 
of information which Is tin some way "sensitive". Thus the 
problem exists In all its complexity whether or not there Is 
a computer at some point in the transfer process. When a 
computer system is involved, [ft must be so engineered that 
the ability to control the transfer of information [Is not 
lost. The present work is _ concerned with designing 
mechanisms to provide that ability. 

Most of the progress which has been made to date 
in computerized access control has been In the realm of 
time-shared systems. The motivation behind these advances, 
unfortunately, has in general been to give systems 
programmers the ability to test and debug programs without 
accidentally destroying the work of other programmers; it 
has been to prevent the destruction of Information, not to 
control the transfer of that Information. The ability to 
protect privacy in the more general sense has been only a 
by-product of these efforts. That the by-products have been 
Insufficient is clear -- In the IBM System 360, for example, 
hardware read-protect is not provided as standard equipment; 
it ts possible to prevent someone from writing over your 
information, but not to prevent him from reading it. (18) 

A few systems, however, have attempted to provide 
more sophisticated access control procedures. In Multics 


the Multiplexed Information and Computing Service, (2, 5, 
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12, 20, 27) It is possible to specify on a user-by-user 
basis the permissible levels of access to each segment’ in 
the system. But even the Multics access control environment 
is not sufficiently general to provide convenient control of 
access to information at the logical level. 

From a more general viewpoint, the primary 
decisions for an access control design scheme can be taken 
as choices of positions along four dimensions: 


1) The physical level at which to apply access 
control. 


2) The fineness of distinction applied to the term 
"access". 


3) The meaning of the term "user tdentification". 
4) The degree of sophistication employed in 
assigning restrictions to new data files. 

One might, for example, want to associate access control 
information at the work space level, at the file level, at 
the record level, at the fleld level, or at the level of 
individual data items. Similarly, "access" might be divided 
in half -- i.e., "yes" or "no" -- or It might be more finely 
divided to distinguish between "read", "write", etc. Along 
the third dimension, one might use only the user's name; at 
a slightly more sophisticated level, one might employ both 
name and password; and so on. Lastly, an access’ control 
system might assign null access (or full access) to everyone 
for each new file. At the opposite extreme, it might be 


able to discover the nature of the sensitivity of data ina 
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new file by knowing the access characteristics of the 
inputs. The choice of positions along these dimensions 
determines the power and abilities of the access control 
scheme. 

This work approaches the problem of access control 
from the general viewpoint within the framework of MacAIMS 
(the Project Mac Advanced {[nteractive Management System) on 
Multics. (Note: the remainder of the thesIs assumes a basic 
familiarity with the Multics system.) MacAIMS Incorporates 
a relational approach to data management using set theory 
operators for manipulation of relattons. A method for 
controlling access to information its presented which, 
although heuristic [In nature, ts more general than any 
access control scheme in common use today. For each of the 
four dimensions of access control, a position has been 
chosen which appears to provide the appropriate levels of 
power and flexibility for our needs, or else represents the 
limits of our knowledge. Expertence with using the system 
will allow us to determine for each dimenston whether our 
level of distinction is too coarse or too fine, and 
adjustments can be made accordingly. It Is not clatmed that 
the controls presented here solve all the access problems of 
MacAIMS; indeed, several classes of problems are presented 
which they cannot solve. What Is claimed, however, is a 
reasonable first cut at the solution to the access control 


problem in a large scale, set-theoretic data management 
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system, and one which should be readily extendable to 
handling of those problems which we already know about, and 


those of which we are unaware. 
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2. CHARACTERISTICS OF ACCESS CONTROL SYSTEMS 


This section considers briefly the range of issues 
involved in a complete access control system for a 
multi-access computer facility and defines the scope of the 
present work. 

2.1. The Range of Issues 

A large number of people have presented overviews 
of the access control problem; the bibliography provides a 
list of some of those works. In considering such an 
overview, a useful framework to follow Is the physical 
structure of the system. 

At the outermost level, there Is the problem of 
identifying the user at the terminal. A variety of methods 
for tdentification, ftncluding passwords, keys, cards, 
voice-prints, signature recognition, and so on have been 
proposed, but most current writers fail to notice that the 
output of any identification procedure Is translated to a 
bit-string which Its passed to the computer for evaluation. 
Any scheme in which that bit string is constant over time is 
doomed to failure, since the user's password may be had 
simply by taking the trouble to tap his data lIne. A more 


successful alternative is the procedural password, [fn which 
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the user responds at each login with the answer to a 
manipulation performed on a (different) string of random 
digits supplied by the computer. Thus. the password fs 
different at each login. 

On the remaining issues the literature is more 
accurate. Among the problems discussed are tapping of data 
lines, physical security of the computer facility, residual 
data In core and on discs and tapes, audit traftls, privacy 
encoding, program validation, and so on. 

The technology of sharing In general Its not at all 
understood by many, but is understood well by a few. The 
interested reader is referred to (7, 8, 19). 

2.2. Scope of the Present Work 

Of all these issues, perhaps the most critical 
occur at the point where’ information Is released from a 
file. The design decisions along the four dimensions of 
access control determine the behavior of the system at this 
point, and if those decisions are poorly made, no amount of 
work in any other area will make the facility secure. It is 
for this reason that these decisions are termed "primary", 


and it is at this point alone that this thesis concentrates. 
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3. CURRENT ACCESS CONTROL SYSTEMS 


The literature concerning what one ought to do 
about access control is supplemented by a much smaller 
literature about what has been done. The relative 
importance of access control issues in the past is perhaps 
best Illustrated by the fact that the System 360 Principles 
of Operatton devotes roughly one-half page to the issue of 
protection. (18) 

This section surveys some access control schemes 
currently in use, and points out their shortcomings. 

3.1. Common Systems 

IBM's most stgnificant efforts to provide access 
control are perhaps three: In the CP67/CMS System, files 
may be released to (all) other users In one of four modes: 
read only, read/write, read only and erase after one read, 
and read/write and erase after one read. However, the 
manual notes that all modes may not be implemented. (3). At 
about this same level of sophistication are the access 
specifications for the APL language; the owner of data may 
specify a password (which ts the same for all users) to 
control access to a work space. (9) Somewhat better is the 


TSS/360 System, which allows” specification of access 
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restrictions on a user-by-user basis with modes” read, 
read/write, unlimited, and restricts. (26) 

In the later versions of the PDP-10 monitor, 
Digital Equipment Corporation supplies a rudimentary access 
control system. The term "user" is separated into three 
categories: 1) the file owner, 2) persons on the same 
project as the owner, and 3) everyone else. Access toa 
file may be restricted for each of these three groups by 
read protection, write protection, and protection 
protection, where the last category Implies the capability 
to change access control [nformation. In addition, it fs 
possible to name files such that the monitor knows they are 
procedures. This feature may be used to enforce "execute" 
access mode. (21) 

M.I.T.'s CTSS supports a fille system which is 
organized as a tree structure, and provides for sharing of 
files through IInks between branches of the tree. Access 
modes are essentially read, write, protected, and any 
combination thereof, and may be assigned at the time the 
link is established on a user-by-user basis. (4) 

3.2. Qther Systems 

All of the systems. listed above provide 
more-or-less sophisticated access control at the file level. 
Several other systems have been proposed (and in some cases, 
implemented) which protect data at a lower level. 


The TERPS system (24) allows protection at the 
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record level withtn files by associating a descriptor with 
each file which contains a security code for the fields. 


However, the term "access" seems to be divided only Into 


yes" or "no", Restrictions may be based on terminal 
location, password, and security level. 

Hstao (17) has proposed a somewhat similar system, 
although {tt is not clear whether Implementation Is past the 
pilot project stage. He distinguishes between the system 
manager, the owner of a file, and other users, and allows 
protection of Individual records within files. 

Hoffman (16) has developed a system which Is 
considerably more powerful than any of these. In his 
scheme, all accesses to a data base take place through an 
intermediary program (which may be different for each user) 
called a formulary. The owner of a file supplies these 
formularies. The use of a procedure instead of table 
lookups to control access allows his scheme to be much more 
clever in assigning access privileges. 

3.3. Limitations 

The limitations of these systems should be 
obvious. Several of them provide control at a physical 
level too high to be of much use. Protection at the file 
level requires that every data item in a file have exactly 
the same sensitivity; at a minimum this restriction 
requires breaking up a logical data base into a number of 


physical data bases. In non-military sttuatltons, where 
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neither users nor _ information are structured as strictly 
ordered hierarchies, such a division is frequently 
impossible. 

Moreover, the term "access" is not finely 
subdivided. At best, only physical actions are 
distinguished (i.e., read ys. write); at worst the term is 
divided in half. Constraints cannot be based on the logical 
actions which the user wishes to. perform. One cannot 
specify, for example, that a user may only extract means and 
medians. 

In several of the systems, it is not even possible 
to make restrictions based on the user's Identity. DEC does 
not allow one to specify that "Smith can see anything tn my 
files" within the context of its standard access control 
mechanisms, although such a specification might be 
implemented by special programming and the "execute only” 
mode. 

Only Hoffman's scheme does not suffer from any of 
these complaints. The tdea of using procedures, though 
simple, is very powerful. Unfortunately, the job of 
supplying the formularies is left to the originator of 
sensitive data; such a task might be quite formidable. 
Moreover, there seems to be no provision for protecting the 
user of sensitive Information (who might have some sensitive 
data of his own) from the effects of the formularies he 


uses. 
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In addition, none of the schemes mentioned so far 
provide the user with any more than minimal afd along’ the 
last primary dimension of access control: he must specify 


one-by-one the access rights to any new files in the system. 


The Multics system provides a much better (though 
still insufficient) access control system. Like CTSS, the 
Multics file system is a tree structure; It contains both 
directory branches, which contain only pointers to inferior 
branches, and non-directory branches, which are data 
segments, procedure segments, and so. forth. Unlike CTSS, 
however, access control in Multics Is associated with 
branches of the tree, not with’ links; a user's access 
rights are evaluated each time a segment Is made known to 
him. 

Permissible access modes are read, write, execute, 
append, and combinations thereof, and may be assigned on the 
basis of users and projects. The access modes [Imply the 
obvious intent for non-directory branches; for directory 
branches the meaning is somewhat different. (20) Access 
Control Lists (ACL's) associated with each branch contain 
the necessary access control data. 

In addition to the file system structure, Multics 
provides a ring structure for protection which is 
essentially a generalization of the common "user" 


state/"supervisor" state idea. The mechanisms provided are 
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similar to those described by Dennis and Van Horne (7); 
some of the limitations of the rings are described in (11). 
For our purposes, the important charactertistic of the ring 
mechanism is that it allows one to specify that his data may 
be accessed only via a program of his own choosing. Any 
attempt to access data from an insufficiently privileged 
ring must take place through a gate Into the more privileged 
ring. It is thts mechanism which allows MacAIMS to help 
protect data for its users. 

Multics also provides some aid in assigning access 
to new segments. The user may specify for each directory a 
Common Access Control List, which contains default access 
assignments for segments in the directory. In addition, 
certain conventions are followed in assigning access to new 
segments created by various compllers and other routines, 
based on the type of segment created; thus object code 
segments are assigned read/execute access. 

From MacAIMS's viewpoint, the most important 
limitation of the Multics access control scheme is that its 
permissible access capabilities, like those of the other 
systems mentioned, are not sufficiently general for powerful 
access control. For example, a perfectly reasonable 
restriction to place on the <Name, Salary> set might be 

"Smith is allowed to extract statistical data on salary 


distributions, but not to see individual's names and 
salaries." 
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Such a restriction is not expressible in the standard 
Multics scheme, though it could be implemented by = special 
programming via the ring structure. Thus the term "read" 
does not discriminate finely enough. It is necessary to 
subdivide this capability. Like Hoffman's scheme, simply 
giving the user the ability to write his own access programs 
is not very much help. 

Moreover, Multics controls access only at the 
file level, and therefore has the inherent limitations 
common to such schemes. 

3.5. The ADEPT-50: automatic classification of new files 

In addition, the Multics rules for assigning 
access to new files are insufficient. A more sophisticated 
scheme for handling new files is presented by Weissman (29). 
He views a new file as being constructed by operations which 
combine information from existing input files, each of which 
has been assigned a level of classification. The essence of 
his solution is to assign the new file the maximum 
classification level (minimum access privileges) of the 
inputs. In addition, subsequent operations on the file may 
lower the user's access privileges. 

Such a scheme is perhaps adequate in the military 
environment; in the non-military world it is insufficient. 
For example, suppose that the set <Name, Group, Salary> 
exists, that it contains information for all people 


associated with Project Mac, and that the <Salary> field is 


3. Current Access Control} Page 24 


considered sensitive. Suppose further that a user Is 
authorized to print salaries of people at Mac who are also 
associated with the School of Management, but is not 
authorized to print anyone else's salary. He would not have 
access to print the entire <Name, Group, Salary> set, but he 
should be able to derive (in our system, via set operations) 
a set which contains only Management personnel, and then be 
allowed to see the results. Thus it must be possible to 
obtain a set to which the access is greater than the access 
to the Input from which it was derived. 

Both the standard Multics scheme and the ADEPT-50 
scheme are therefore inadequate for our purposes. Before 
presenting a design which corrects some of these problems, 
it Is necessary to describe briefly the structure of 


MacAIMS, 
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4. MADAM: 
SET-THEORETIC RELATIONAL APPROACH TO DATA MANAGEMENT 


This section provides an overview of the MacAims 
Data Management System. For a more complete introduction to 
relational data management and MacAIMS, and a detailed 
description of MADAM, the interested reader is referred to 
C13,- 16, 25), 
4.1. Description of MADAM 

MADAM operates under the assumption that = any 
information which is to be stored or manipulated by the 
system consists of sets of Data Elements (DE's) and of sets 
of relations among those data elements. The DE's themselves 
are stored in Data Element Sets (DES's), and the relations 
in Relational Data Sets (RDS's). The primitives of set 
theory are the operators used for manipulating RDS's. 

Suppose that there exist DES's DESI, DES2, DES3, 
-»-, DESn. The RDS which expresses relations among elements 
of these DES's will contain n-tuples (tuples of order n), 
each of which has as its first entry a DE from DESI, as’ Its 
second entry a DE from DES2, etc. The first tuple In the 
RDS will contain the names of the sets DESI, DES2, and _ so 


on, and is called the Relation Descriptor (RD). Thus, for 
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example, there might be two DES's: 

Name 

Jones 

Smith 

Hilphenhauser 

and 

505 

806 

301 


The entries "Jones", "Smith", ... "505", etc. are the DE's. 


The RDS which expresses the relations might then be: 


Name OF Fh ice 
Jones 505 
Smith 806 
Hilphenhauser 301 


Here, <Name, Office> is the RD, and the 2-tuples of the RDS 
are <Jones, 505>, <Smith, 806>, and <Hilphenhauser, 301>. 
In addition, the columns of the RDS are referred to as 
flelds: this RDS has two fltelds, and thelr fleldnames are 
"Name", and "Office". The information In this set Is the 
fact that Jones's office is 505, that Smith's office is 806, 
etc. Neither the character string "Jones", nor the Integer 
"505" alone necessarily carry any Information. 

At the time when a data element first enters the 
system, it is assigned a untque identifier which Is used 
thereafter to reference it. This tdentifier Is the 
Reference Number (RN), and In the current Implementation Is 


a 36-bit bit string which may be referenced as an _ integer. 
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RN's are not basic to the system; they are used for 
computational and storage efficiency. Programs called Data 
Element Modules (DEM's) are provided which obtain Data 
Elements as input, convert them to the internal storage form 
(the Standard Form, SF), store them in DES's, and assign 
their Reference Numbers. DEM's are also called to output 
SF's In human-readable format. Thus there might be a DEM 
which handles dates, one which handles names, one which 
handles integers, and so on. 

In order to construct and manipulate RDS's, 
programs called Relation Strategy Modules (RSM's) are 
provided. There ts one RSM for each storage strategy 
supported by the system; thus, there might be an RSM _ for 
list structures, an RSM for trees, etc. In the example 
above, the RDS Is represented as an array, and the DE's are 
shown as being In the tuples of the array. This 
representation suffices for the logical content of an _ RDS 
and wlll be used throughout this paper, but It should be 
remembered that RDS's are not necessarily arrays, and that, 
in any event, in the current Implementation they contain the 
RN's of the DE's, not the DE's themselves. 

Each RSM provides the following set primitives for 
manipulating RDS's: 

intersection 
difference 
projection 


jotn 
composition 
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product 
union 
These operations require two RDS's as input and produce a 
new RDS which contains the result of the operation. 
Intersection and union perform fn the obvious’ manner; 
difference yields all members of the first input which are 
not in the second; projection removes unwanted fields or 
permutes fields; join forms an RDS which contains all the 
fields of both Inputs along with those tuples which match on 
the inputs' common fields. Composition requires that the 
last field of the first fnput be the same as the first fleld 
of the second, and it produces an RDS which does not contain 
the common fleld, but does contain those tuples which 
matched. Product Is the Cartesltan product. 
In additton, several non-set primitives are 
provided: 
A set Is ordered by use of 


get_successor 


For a_ given tuple, get_successor returns the next tuple in 
sequence. 
For efficiency the operations 
replace_tuple 
find_tuple 
are defined. Both are redundant in that they could be 


performed by combinations of set primitives. Find_tuple 
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searches an RDS for a given tuple; replace_tuple raplaces a 
tuple in an RDS. 
The mechanisms for creating RDS's are also 
furnished: 
create_set 
insert_tuple 
The create_set operation is used to define a new RDS, and 
takes the necessary steps to establish its storage, its RD, 
and {ts associated DEM's and RSM. Insert_tuple inserts a 
given tuple Into an existing RDS. Thus these two operators 
provide for original data entry Into the system. 
For details of the functions of these operations, 
the reader Is referred to (25). 
In addition to the Reference Numbers assigned by 
DEM's, there are two special RN's: the "wild card", 
represented by "*", which Is constdered to match any RN; and 


W----") which Indicates a null 


the null RN, represented by 
DE. Thus the tuple 

<*, *> 
matches any of the three tuples In the above example. The 
tuple 

<Jones, *> 
matches <Jones, 505> above, and would also match any other 
Jones's In the RDS. The tuple 


<Jones, ----> 


matches none of the above tuples, but would find any Jones's 
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who had no office in the RDS. 
4.2. Implications for Access Control] 

The philosophy and the design of MADAM have 
several implications for the design of its access control 
mechanisms. 

The set operations provided by MADAM are powerful 
in that they allow concise specifications of large amounts 
of work. The access control scheme must provide similar 
power through conciseness of expression, or it will 
significantly detract from MADAM's usefulness. Ina company 
employing 50,000 workers, for example, I[t might be entirely 
unacceptable to specify access to a particular RDS by a list 
of names: an access list of 3,000 people would be entirely 
unmanageable. 

Moreover, the fact that data bases might be very 
large implies a great deal of sharing of physical data 
between users who have widely varying charactertstics and 
Information needs. A rather fine distinction of the logical 
types of access to a data base is needed, so that precise 
levels of control may be applled in a variety of 
circumstances. The term "read access" is too coarse a 
distinction to be useful. 

Last, the use “of set operations to obtain 
information from the data bases implies a large number of 
temporary RDS's containing either Intermediate results or 


special relations which are useful for some application. A 
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single interaction with the main data base might cause the 
creation of several new RDS's. Therefore simple-minded 
schemes for assigning access privileges to new files are 
insufficient; a fixed default would not characterize 
properly more than a few of the new sets. In addition, 
placing the burden of assigning access privileges for new 
sets on the originator of sensitive information would 
discourage almost anyone from storing such information in 
the system. Even Weissman's ADEPT-50 scheme Is far too 
simple; MacA!IMS access control must provide the originator 
of sensitive information with much more significant ald In 
assigning access rights to new RDS's. 

The access control schemes presented In Section 3 
have chosen positions mione the four dimensions of access 
control which are too naive for the purposes of MacAIMS. We 
turn now to the design of a scheme which exhibits much more 


power and generality. 
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5. THE MACAIMS INTERIM ACCESS CONTROL SYSTEM 


This section describes the initial access control 
mechanisms for MADAM. The system outlined here is an 
"interim" system In the same sense that MacAIMS itself Is In 
an interim state: we do not at this time fully understand 
all the problems (let alone their solutions) associated with 
access control. Therefore, a first approximation access 
control system Is provided which will yteld aie simplified 
solution to the general problem as well as a base from which 
to experiment with more powerful algorithms for control. 
Moreover, the system described here Its "primary" In that It 
is limited to the issue of Interaction of an fdentified user 
with system Information. 

The interim access control system Is considered 
first at the level of basic assumptions, then at the user's 


level, and finally at the system design level. 
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5.1. Basic Assumptions 

In order to delimit a common ground for discussing 
the primary access control problem in the context of 
MacAIMS, the following basic assumptions are enumerated. 
5.1.1. Definition of Access Control 

For the purposes of this. study, the following 


definition of access control is sufficient: 


Access Control is defined as the restriction of the use 
and dissemination of sensitive information to 


authorized entities. 


This definition merits further clarification: 

Entity is defined to be the party requesting 
access. Roughly speaking, this Is the user of the system, 
but the intuitive meaning of "user" is insufficient for our 
purposes. I[n MacAIMS the requesting entity corresponds more 
nearly to the concept of a "computation", as expressed by 
Dennis and VanHorn (7), and is precisely defined by a list 
of characteristics associated with the state of the system 
at the time access is requested. The list includes as a 
minimum the standard Multics Identification characteristics: 

1) User_id (name) 

2) Project_id (project) 


3) Instance tag 


and may be arbitrarily extended to include any other 
information about which MacAIMS has knowledge or can be made 


to obtain knowledge. Such extensions logically include 


Og ee ee Se ee a ee 
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characteristics like: 

4) Terminal_id (the terminal identifier of the 
process requesting access. This characteristic is 
fairly commonly used in military security systems, and 
will be provided in MacAIMS for the sake of generality, 
but it is not considered to be especially secure for 
the purposes of access control, since terminal id's are 
relatively easy to change.) 

5) Program_id (the procedure requesting access.) 

6) Time of day 

7) Day of the week 


etc. 


Information in MADAM is considered to reside only 
in Relational Data Sets. It is therefore those sets which 
are to be protected. 

Information is sensitive as long as there are 
conditional restrictions on its use or dissemination. Such 
restrictions may be placed on information efther by its 
originator or by any other party to whom he grants’ that 
capability. If all fields of an RDS have the maximum 
possible access rights, then the Information is not 
sensitive, and the access control system need no longer be 
concerned with it. The possible levels of sensitivity 
allowed by the interim access control system are described 
in Section 5.2.1. below; the procedures and data which 
describe the conditions of sensitivity may be completely 
arbitrary. 


Use of information is defined by an operator which 
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an entity requests be applied to that information. In the 
interim system, possible operators are restricted to those 
performed by Relational Strategy Modules, i.e., the set 
theory operators and the non-set primitives. 

Dissemination of information is distinct from use 
by virtue of being a "final result" from the system's 
viewpoint. Dissemination implies the passing of informatton 
beyond the boundary of the access control system's ability 
to restrict. 

An entity is guthorized to request an’ Interaction 
(a use, a dissemination, a write, an append, etc.) with 
existing information If his characterfstics and the 
operation's nature and the result of the request satisfy the 
sensitivity constraints which have been placed on the 
information. It will be demonstrated that al] of these data 
must be considered in determining permisstble access levels. 
In the interim system, the levels of authority granted (as 
well as the levels of sensitivity) are constrained to fall 
into a fixed set of access capabilities described below. 

Finally, yrestriction is the act of constraining 
information accesses to those authorized in the above sense. 
5.1.2. System Characteristics 

The following general (and rather obvious) 
characteristics are desired in the [Interim access contro) 
system. 


In order to be immediately useful, the intertm 
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system must be general in the same ways that MADAM itself is 
general. It must not place any restrictions on the nature 
of the actual information which it protects. Second, and 
somewhat more difficult, it must allow considerable 
flexibility in the ways the owner of sensitive information 
may express the conditions of sensitivity. 

The system must be extensible since it will not be 
a complete solution to the problems of access control. It 
must eventually be extended to include solutions to the 
problems which it does not now solve, as well as_ solutions 
to problems which we have not forseen. Since the decisions 
along each of the four dimensions of access control 
discussed in Section 1 are arbitrary, it must be relatively 
easy to change those decisions as experlence dictates. More 
important, individual users must be able to extend the 
access control mechanisms in arbitrary ways to handle their 
own special requirements for control. 

There must, however, be some limit to these 
arbitrary extensions, lest the situation weiss where every 
user has his own access control system which is_ so 
specialized to his needs that It cannot communicate with any 
ether user's. system. The interim system provides this 
common framework for communication by fixing the set of 
assignable sensitivity (and authority) levels. The set, 
however, Is fixed by choice, not by any inherent limitation 


of MacAIMS. 
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The interim system must be compatible with the 
rest of MADAM in the sense that it utilizes both the data 
storage mechanisms and the operational mechanisms provided 
by MADAM to do its work. It fs this compatibility which 
provides the interim system with the ability to meet the 
first two design goals. In additton, the access control 
system gains great power because the large body of tools 
available in MADAM become available for manipulation of 
access information. Moreover, compatibility means that as 
MADAM becomes more powerful, the access control system will 
gracefully evolve in a similar fashion. 

Lastly, the cost of controlling access (in terms 
of both user effort and computation time) should vyary 
directly with the complexity of the sensitivity description 
of the data; detailed and sophtsticated descriptions should 
be expected to cost more than simple ones. Any user who 
wishes to interact with someone else's sensitive data should 
expect to pay in proportion to that sensitivity. Moreover, 
a user who does not desire protection should expect his 
costs to be somewhat lower. 

5.1.3. Design Assumptions 

Other assumptions upon which the following 
description ts based are those implied by Section 2.2. 
above: namely, the entire range of access control problems 
that physically exist between the user station and the CPU 


are not considered. All Information concerning the user's 
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identity and the other characteristics which identify the 
requesting entity is taken to be accurate; verification of 


that data is a separate problem. 
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5.2. Design Specifications 

This section outlines, from the user's viewpoint, 
the interim access control system's appearance and behavior. 

At the outset [it should be noted that it is not 
feasible to store access control information on a tuple by 
tuple basis in MacAIMS, even though the tuple is’ the basic 
unit of information. Such schemes would require more 
storage and computation than reason permits, and would make 
the user's task in specifying access control information 
impossibly large. This does not imply that one cannot 
specify constraints that affect single tuples or small 
groups of tuples within an_— RDS. Even in these cases, 
however, the access control information Is not physically 
attached to the individual tuples. 

tt Is also unreasonable to provide access control 
on an_ RDS by RDS basis, since this level of control is too 
superficial to allow sufficiently general specifications of 
sensitivity. Suppose, for example, that the RDS <Name, 
Salary, Religftous-Affiliation> were created. Both salary 
and religious affiliation would probably be sensitive, but 
there is no reason to believe that the nature of the 
sensitivities would be the same. Access control information 
is therefore retained on a field by fleld basis within 
Relational Data Sets. 
5.2.1. Access Capabilities 


A user may request the transfer of information 
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from an RDS to himself for two (and only two) logical 
reasons -- he may wish to use the information as data in 
calculating other information which he needs (i.e., he may 
wish to use it in the sense of Section 5.1.1.) or he may 
wish to view the information itself as a final result (Che fs 


requesting dissemination). However, the concept of "use" Is 


still too general for access control. It is necessary to 


distinguish still further, and for the interim system, "use 
has been split into two categories: manipulative and 
statistical use. Manipulation means the application of the 
set theory operators provided by MADAM; statistical use Is 
the extraction of means, medians, and so forth. This 
subdivision is strictly hierarchical, so that the concept of 
"increasing access" will have meaning. 

Thus there are the following four levels of access 
for Information which flows from an RDS to aéeuser. In 


increasing order (by the amount of information which they 


release) they are: 


N -- null; no access is permitted. (This ts the 
default access unless the originator of the information 
specifies otherwise.) 


M -- manipulate; the user is permitted only to apply 
set theory operators to the Information. He may or may 
not be allowed to see the results of that manipulation, 


depending upon the access restrictions of the data. 


S -- statistical; the system will permit dissemination 
of statistical data about the Information only. 


P -- print; the system will disseminate the 
information. 
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Each of the lower access capabilities is 
considered to be a proper subset of the next higher 
capability. Thus S access includes the right to manipulate 
the information. 

It is implicit in the above statements that the 
programs which the user invokes in order to apply set theory 
operators or statistical operations are either standard 
MacAIMS programs or other programs whose performance has 
been "suaranteed" to the access system's satifaction. In 
order to apply arbitrary programs to protected data, the 
user must possess the capability to have the information 
disseminated (P access). . 

The diviston of "use" into N, S$, and M is clearly 
somewhat arbitrary. It might, for example, be desirable to 
provide even finer levels of distinction by further dividing 
S into the capability for extracting the mean, the 
capability for extracting the standard deviatton, and so 
forth. It would seem, however, that the divisions expressed 
here are at about the appropriate level of distinction for 
most management data in the context of MacAIMS; only 
experience with using the system will allow us to judge more 
surely. 

Similarly, there is a hlerarchy of capabilittes 
for the flow of information from an entity to an RDS. These 
capabilities are essentially those provided by Multics, 


except that they are viewed as a strictly ordered hierarchy 
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of privilege rather than as discrete but equal divisions. 


In increasing order, they are: 


N -- null; no access is permitted. (This is the system 
default.) 
A -~- append; the user may append relations to the 


“end" of the RDS (where "end! is the logical, not the 
physical, end), but he may not change information whfch 
is there already. 


W -- write; the user may change existing information 
or add information to the RDS. 


C -- change access; the user may manipulate the access 
control data which is associated with the flelds of the 
RDS. 


There are [In addition two capabilities assoclated 
with each RDS with which the user need not normally concern 


himself, since they are assigned and matntained by the 


system. They are: 


0 -- ownership; the owner of an RDS is the user who 
caused its creation. He may therefore delete it. 
(Note that this does not imply the € capability or any 
other; an acquired data set belongs to whoever caused 
its creation, but has access capabilities determined by 
the sets which were used to derive It. Thus a user may 
derive a set to which he has no access; however, since 
he owns it, he can get rid of it.) 


Ac -- acquired; an indicator that the RDS contains 
Information which was not originated by the owner. A 
data set is acquired unless 1) it was created through 
the use of the primitive operations "create_set" and 
“insert_tuple" or 2) is made from RDS's which were not 
acqufred and which are owned by the user in question. 
The acquired flag being off Implies the € capability. 


Thus In the MacAIMS access control system, there 
are three distinct concepts which [In more conventional 
systems are lumped together under the term "owner". First, 


there is ownership, which tImplies responsibility for 
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creation of an RDS and the right to delete it. Second, 
there is the concept of the originator of information 
(acquired flag off), which implfes ortginal entry of a1! 
data in the RDS and therefore the rights of ownership and 
access changing. Last, there [ts the ability to change the 
access control specifications, which falls to the originator 
and to whomever else he specifies. The interim system does 
not, therefore, provide mechanisms for resolution of 
conflicts of privacy. Such issues must be solved through 
extensions of the current scheme. 
5.2.2. Description of Access Rights 

it ts clear that In the non-military world there 
are many different ways In which one might wish to specify 
sensitivity constralnts on Information which its to be 
protected. tn the simplest (and probably the most common) 
case, one might list all the people who can (or cannot) 
access the Informatlon, along with what type of access’ they 
have. Such a scheme’ fs supported by Multics. There are 
many cases, however, where such a listing fs either 
inconventent or Impossible. tt Is therefore desirable to 
provide more powerful mechanisms for specifying the 
conditions under whtch one's Information should be released. 
Such statements as "Anyone may see Information about 
himself" or "Anyone above the level of plant manager may see 
the personnel data" should be concisely expressible. It Its 


not possible, obviously, to delimit every way in which such 
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constraints might be stated, nor would one support them al] 
if it were; the access system must be simple enough to be 
comprehended if it is to be used. Support is therefore 
provided for a number of ways to express access control 
restrictions which should be general enough for most 
purposes. In addition, we provide a mechanism by which the 
originator of information can specify procedures of his own 
choosing for access control. 

The originator of information and those users to 
whom he has granted the C capability may specify, for each 
level of access capability, conditions for its release by 
the following tests: 

1) Test on the list of characteristics of the 
requesting entity: He may specify tests to be made on any 
of the characteristics of the requesting entity listed in 
Section 5.1 above and Included in the state set of the 
system (see "The Access Control Data Base", below). Such 
tests logically take the form 

"Jones has P access" 
"if <user_id> = Smith and <terminal_id> = a64 and <day> 
= Friday, then access = M" 
and so forth. They may also be "negative" specifications, 
such as 
"if <user_id> “= Smith then access = P" 
With this test, as with all others, a default access may be 


specified which Is logically equivalent to an "else" clause 
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and which will take effect if all tests fail. If no default 
is given, the system default is null; the system Is 
basically closed rather than basically open. 

2) Test on the content of the sensitive domain: 
He may specify access restrictions based on the content of 
the fleld in question. For example, If salary is a 
protected field, a constraint might take the form: 

"if <salary> = 100000, then access = N" 

The interim system supports only statements which are 
expressible in terms of the existing MADAM operators, i.e., 
only matching is allowed. This implementation’ restriction 
probably makes tests on content alone less useful; one 
would generally want to make statements such as "If salary 
is less than 10000 then...". This simple “less than" 
constraint would be easy to handle, but it is a special case 
of the problem of subsetting based on general logical 
restrictions (which Its under study at MacAIMS) and will 
therefore not be solved separately. For the present such 
constraints must be handled by spectal programming. Since 
the access control system uses MADAM constructs exclusively, 
however, such capability will be available to the access 
system when it Is available to the rest of MADAM. 

3) Test on the context in which the sensitive 
domain appears: He may specify constraints based on the 
context In which the fleld in question may appear. These 


context restrictions may be based only on the fieldname of 
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the other field, i.e. 
"salaries may not be printed in conjunction with names" 


or they may be based both upon the fieldname and its 
content: 


"salary may not be released if it is seen in conjuction 

with name and name = George" 
The first of these will be called a simple context 
r iction, the latter, complex. This distinction is 
necessary for computational purposes, as described in 
Section 5.4, but is not basic to the logic of access 
control. 

4) Proper completion of an interactive procedure: 
He may specify that users supply a password (perhaps a 
procedural password as described in Section 2) at the 
console in order to obtain access. The system interactive 
access routine will provide for one challenge and response; 
any more fancy interaction will require special purpose 
programming. 
5) Any combination of methods 1 - 4: He may 

specify combinations of the above; for example, 

"Jones may see salaries if salary appears’ in 

conjunction with the field <group>, and the contents of 

<group> are the same as his projectid" 

(requesting entity characteristics + complex context.) 


It is felt that this level of support of access 


description is general enough to handle the majority of 


MacAIMS access problems. At the same time, by allowing the 
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user to specify access control by stages, considering first 
the system state, then the content of the field, etc., the 
system should be reasonably easy to _ use. Moreover, the 
simpler the restrictions, the simpler they are to specify. 
5.2.3 Acquired Relation Sets 

A relation set is "acquired" only if it is 
obtained by combining existing relation sets that contain 
information which was not originated by the owner. Thus 
(obviously) all acquired relation sets are new sets, but 
(not so obviously) all new relation sets which are the 
output of a set operation are not acquired sets. Ifa user 
combines sets which contain only information which he 
originated, the new set is conceptually Identical to a _ set 
formed by using "create_set" and "insert_tuple", and it is 
therefore not acquired. Im MacAIMS as it now stands, sets 
are acquired only through the standard set operations 
provided by the RSM's; presumably it will one day be 
possible to derive sets by other means. 

In any event, it is the system's responsibility to 
maintain appropriate access control to_ information in 
acquired sets. Not only are access privileges automatically 
assigned to the acquirer, but also an Access Control List is 
assigned to the acquired set which will maintain proper 


control even if the set is passed on to other users. 
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5.3. System Overview 

This section provides an overview of the destgn of 
the Interim Access Control System. The access control data 
base and the MacAIMS Access Restriction Module (MARM) which 
Is responsible for maintaining that base and for using it to 
control access are described here; subsequent sections 
discuss in detail the representation of access information 
and the rules for computation of access rights to acquired 
relation sets, as well as methods for defining access rules 
in non-standard ways. 

MARM {is the overseer program for access control, 
and is invoked at each attempted access to _ sensitive 
Information. The other major program modules which assist 
it are the access handlers, each of which evaluates its data 
and returns a boolean value Indicating whether its 
constraints are satisfied, and the RSM for evaluated 
functions, which maintains RDS's whose tuples require 
function evaluation. In addition, the ACL_bullder provides 
aid tn constructing Access Control Lists. 

5.3.1. The Access Control Data Base 

The following pages detail the access control data 
base as it logically exists within MADAM. In some cases, 
the physical data base may differ slightly from the logical 
data base for reasons of programming expediency, but such 
differences are not relevant here. 


It is implicit in the discussions of Sections 5.1 
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and 5.2 that there are two general classes of information 
which are necessary for access control. First, there is 
information which pertains to the characteristics list of 
the entity requesting access; second, there is information 
which details the nature of the sensitivity of information 
to which access is requested. All information regarding the 
characteristics of the requesting entity resides In the 
“state set" of the system, which has the form of a MADAM 
RDS, and all information regarding the sensitivity of the 
fields of RDS's resides In the "Known RDS Table" and its 
associated Access Control Lists. 
5.3.1.1. Requesting Entity Information: the state set 

The state set is logically a_ single tuple of 
degree n where n is the number of characteristics assoclated 
with the requesting entity. It ts an RDS with only one 
entry besides the relation descriptor, and has the form: 

<User_id, Project_id, Instance_tag, Terminal_Id, ....., 
Program_id, Time, ...>? 

"..." represents any other Information which the system 
chooses to support for access control purposes; such 
cholces should be based on user demand. <Program_id> 
includes both the program name and entry name of the program 
active when the attempted access occurred. 

The state set is accessed via the 
RSM_evaluated_functions_, and Is a special case of the 


larger class of RDS's which that RSM supports. An RDS 
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Associated with each data base In the system Is a 


(logical) RDS called the Known RDS Table (KRDST). The KRDST 


is made up of two physical RDS's. The first, called the 


zy KRDST, has the form 


<RDS_name, Le es Ownership, Acquired_flag, 
Restriction_flag, False_content_flag, 
False_context_flag, Time_of_reference, ACL_control_rds> 
where ACL_control_rds points to the second part of the 


KRDST, which is called the ACL_control RDS, and has the form 


<Fleldnumber, Access, ACL_rds> 


The user's data base begins with an empty KRDST; 
T.e., no RDS's are known to him. At the first requested 
reference to an RDS, an entry tn the KRDST Is made, and the 
user's current access privileges to each of the n fields of 
the RDS are evaluated and stored In the <access> indicators 
of the ACL_control. When a set operator Is performed which 
results in the creation of a new relation set, the Input 
sets are checked against the KRDST and entered If necessary, 
and the new set is appended In a stmilar fashion. 

The fields of the KRDST and thelr uses are as 

follows: 

1) RDS_name (the name of the Relation Data Set) 

2) ... (other Information which the system needs 
to keep regarding the RDS, but which ts not directly 
related to access control; this might [Include polnters 
to the physical location of the segment, etc.) 


3) Ownership (the tndicator of whether the RDS Is 
owned by this user, as described In Sectlon 5.2.1.) 
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4) Acquired_flag (the indicator of whether the RDS 
is acquired, as described in Section 5.2.1.) 


5) Restriction_flag (on if there are content or 
context restrictions on any field of the RDS) 


6) False_content_flag, False_context_flag (for a 
acquired set, an indicator of whether operations have 
been performed in the derivation history of the RDS 
which make fit impossible for the access control system 
to guarantee that the content/context is "True," This 
problem is discussed in detail in Section 5.5. Fora 
set which is not acquired, the flags are off.) 


7) Time_of_reference (the time of the last 
reference to the RDS) 


8) Fieldnumber, Access, ACL_rds (These represent 
the information necessary to compute access to field 
<fieldnumber> of the RDS in question. <Access> is the 
user's currently computed access privilege level, and 
is computed at the time the KRDST entry is made from 
the information contained in the ACL's which = are 
pointed to by the ACL_rds's. (In the case of an 
acquired data set, it will be computed from the ACL's 
of the input RDS's). At each reference to the RDS, the 
Time_of_reference is checked against the time of last 
modification of the ACL's pointed to by the ACL_rds's, 
and if they have been changed, access is recomputed 
before any information is released. More than one ACL 
may be associated with a particular field (this occurs 
primarily with acquired relation sets). Multiple ACL's 
are represented by multiple entries tn the ACL_control; 
in these cases, all of the ACL's for field i are 
evaluated, and the minimum returned access is assigned. 
This is equivalent to logical "and": if ACLil 
specifies P access under conditions X, and ACLi2 
specifies P access under conditions Y, then P will be 
granted to field i only if X "and" Y is true. The 
methods for computing the access level and for 
determining the ACL of an acquired data set from the 
ACL's of its inputs are discussed below.) 


There is one KRDST per data base in the system. 
Note that some data bases may be temporary (per Multics 


process), and as such will be destroyed when the user logs 


out unless explicitly saved. 
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The ACL's (which may be the same for many RDS's) 
are themselves RDS's with the following format: 


<Access_level, And_flag, Access_handler, Data_type, 
Data_rds> 


The meaning of the fields are as follows: 


1) Access_level, Access_handler, Data_rds 
(Access_handler is the name of a program which may be 
either system supplied or user supplied and _ which 
operates on the data structure pointed to by Data_rds 
in conjunction with such system state data as necessary 
to return one of two values -- either "The conditionals 
specified are satisfied", (True) or "The condittonals 
specified are not satisfied". (False) If the response 
is True, then the permissible level of access is. that 
implied by Access_level.) 


2) And_flag (used to link together entries of the 
ACL as being part of the same conditional 
specification. if two (or more) tuples are linked 
together by the And_flag, both access handlers must 
return true in order for Access_level to be granted. 
This ts a logical "and", and tuples linked in this way 


are called And groups.) 


3) Data_type (specifles the nature of the data 
pointed to by Data_rds.) 


Entrles in each ACL are in decreasing order by Access_level. 
At this point it is possible to draw the logical 
structure of the access control data base, as shown in 


Figure 1). 
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5.3.2. MARM: The MacAIMS Access Restriction Module 

It is MARM's responsibility to oversee the access 
control data base, to keep it up to date by assigning access 
appropriately to RDS's in the KRDST, and to perform the 
function of restricting access to authorized entities. 

MARM “evaluates the access" for a particular field 
i of an RDS by the following procedure: 

1) For: each tuple in the ACL _control whose 
<Fieldnumber> entry is i, “evaluate the associated ACL". 

2) Assign the minimum access level returned by 
these evaluations. 

The procedure for "evaluating an ACL" is: 

1) For each tuple in the first And_group (there 
may be only one tuple), call the access_ handler; if all 
handlers in the group return True, the access level Is 
<Access>. 

2) 1f the first And_group fails, try the second, 
etc. 

3) If all And_groups fail, assign the 
originator-supplied default access. 


4) If the originator supplied no default, assign 


l= 


Thus, evaluating access toa field of an RDS is 
essentially a process of executing a list of programs (the 
access handlers) until one of those programs decides that 


the situation satisfies its conditionals. This process is 
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made somewhat more complicated by the need to "and" these 
programs in order to allow mixed tests, and by the need to 
"and" the ACL's in order to preserve access rights through 
acquired data sets. Whole ACL's may be "“and""ed on the 
ACL_control RDS by use of the <fieldnumber>, and Individual 
tuples within an ACL may be "and"ed by use of the And_flag. 
In any other case, separate tuples in the 


ACL_control or an ACL imply logical "or". For example, the 


ACL: 
Access Leve] Ang Flag Access Handler DT DRefnum 
Progl - Datal 
p ; Prog2 - Data2 


is equivalent to the logical expression: 


"if <Progl's conditionals> or <Prog2's conditionals> 
then access = Pp" 


whereas the ACL 


Access Level And Flag Access Handler DT DRefnum 
Progl - Datal 
: : Prog2 - Data2 


is equivalent to the logical expression: 
"if <Progl's conditionals> "and" <Prog2's conditionals> 
then access = P" 
At each invocation MARM performs the following 
steps: 
1) It checks the appropriate KRDST entries for the 
input RDS:or RDS's; if they are not already known to. the 
user, it makes them known, evaluates the access to each of 


their fields, and makes appropriate entries In the KRDST. 
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2) It checks whether the operation is a non-set 
primitive. If so, it decides whether an access violation is 
implied, either does or does not permit the operation, 
updates the KRDST, and returns. 

3) If the operation is a set primitive, then it 
will result in a new (perhaps acquired) RDS. MARM makes” an 
entry in the KRDST for the new set, and computes its 
ACL_control. The ACL_control entry for each field is the 
union of the ACL _controls of the corresponding fields of the 
input RDS's, with the <fieldnumber> field appropriately set. 
Thus the new ACL_control will cause MARM to perform the 
logical "and" of the input ACL's. If both input fields had 
the same ACL_control, then the new ACL_control (and hence 
the ACL's themselves) is the same as that of the inputs. 
Notice that this algorithm gives new RDS's only a pointer to 
the actual access control data from the input. sets. Any 
subsequent changes in that data will therefore be reflected 
in derived sets; of course, this characteristic may be 
overridden by supplying copies of the data instead of 
pointers, 

4) MARM now assigns the current access privileges. 
If the set operation is neither intersection nor difference, 
the access level for each field is the minimum of the access 
levels of the corresponding fields of the inputs. For 
intersection and difference, the new ACL_control for each 


field is evaluated in the above manner, and the resulting 
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access rights are assigned. It is thus possible to obtain a 
subset (by intersection or difference) to which one has 
access priyileges higher than his privileges to the original 
set. 

5) In either case, MARM decides whether an access 
violation has occurred, takes appropriate action, updates 
the KRDST, and returns. In the Interim system, the response 
to an access violation Is a denial of the request. It would 
be simple to make this action either more severe (ring 
alarms, log the user out) or less severe (release whatever 
information he was really allowed to see), as the situation 


might warrant. 
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5.4. The Standard Description of Sensitive Data 

This section addresses the problem of describing 
the logical constraints placed upon sensitive information. 
The requirement for compatibility with the existing MADAM 
system implies 1) that MADAM constructs be used for storing 
the access control data, and 2) that MADAM operators be used 
to operate on it. In fact such constraints may not be 
concisely expressed In MADAM as it now stands, but’ the 
compatibility requirement overshadows such considerations. 

These descriptions of sensitivity are the RDS's 
pointed to by the <data_rds> field of the ACL when the 
<access handler> is a system-supplled program. 

The essence of the solution which the interim 
access control system adopts is the construction of one or 
more filtering relations. A +Filter RDS represents 
information that may be accessed; a -Filter RDS represents 
information that may not be accessed. Then, given an RDS to 
evaluate (the Requested RDS), a system access handler 
logically intersects it with the filter RDS; the result of 
this intersection is the Accessible RDS. For a +Filter, the 
Requested RDS passes if the Accessible RDS contains exactly 
the same information as the Requested RDS. Since the 
+Filter represents information which can be accessed, all 
the information In the Requested RDS must get through or 
else the Requested RDS contains Inaccessible data. For a 


-Filter, the Accessible RDS must be empty In order for the 
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request to be valid; any information which gets through the 
filter is data to which the user does not have access. 

In the interim access control system, the standard 
access handlers use the set primitive join instead of 
intersection, because join ignores fields which the input 
RDS's do not have in common. Thus filters may be 
constructed without regard for fields which are irrelevant 
for access control. This fact facilitates sharing of both 
filters and entire ACL's between RDS's. 

The logical operators used in expressing 
constraints are "and", "or", and "not". We have already 
seen that adding tuples to an RDS may serve as a_ logical 
"or"; this equivalence also holds within filter relations. 
In addition, the <fleldnumber> field of the ACL_control and 
the And_flag of the ACL, when coupled with MARM's evaluation 
rules, provide two methods for specifying logical "and". 
Adding fields toa filter is yet another way of specifying 
"and": examples below demonstrate that "and" is Implied 
between fields of an RDS on a tuple-by-tuple basis. (Thus, 


a filter containing only "or" constraints has order one.) 


The "not" operator is represented by a -Filter. 
The precise rules by which a requested RDS may 
pass a filter are: 
+Fliter: 1) The join must match all flelds of the 
filter (=> order of the Accessible RDS = order of the 
Requested RDS.) and 2) the number of tuples in the 


Accessible RDS = the number of tuples in the Requested 
RDS. 
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-Filter: For simple context filters, the join 
must fail (¢=> no fields match). For all other 
-Filters, 1) The join must match all fields of the 
filter, and 2) the number of tuples in the Accessible 
RDS = 0. 

The <Data_type> field of the ACL indicates which type of 
filter is pointed to by <Data_rds>. Use of these constructs 
and the evaluation process are best made clear by examples. 
5.4.1. State Set Constraints Alone 

Filters for state set constraints alone are the 
simplest because the structure of the State Set RDS is fixed 
by convention. Thus the context of any state set entry Is 
fixed and the join operation will always match on all 
fields. The "*"' convention may therefore be conveniently 
used in adding constraltnts. 

Suppose, for example, that the [Initial constraint 

on a field is 
"If <User_id> = Smith | <User_id> = Jones | <User_id> = 
Hilphenhauser, then access = P" 
The resulting +Filter would simply be: 
User _id 
Smith 
Jones 
Hil phenhauser 
The result of joining this RDS with the State Set RDS is an 
RDS which contains one tuple if the current user is Smith or 


Jones or Hilphenhauser, and which contains 0 tuples 


otherwise. Since the State Set Is one tuple long, it passes 
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the filter only under the correct conditions. 
Now suppose we wish to add the (completely 
independent) constraint 
"TF <terminal_id> = a64 then access = P" 


This may be accomplished by adding a fleld to the existing 


+Filters: 
d Termi 
Smith * 
Jones * 
Hilphenhauser * 
* a64& 


The first tuple of the filter now precisely expresses the 
constraint 
"If <user_id> = Smith & <terminal_id> = any terminal, 
then access = P" 
but this is no different than the original constraint, since 
all users must be logged in at some terminal. The last 
tuple In the filter matches anyone logged In on terminal 
a64, as desired. Thus constraints may be added without 
regard for previous tuples, as long as "«'" entries are 
appropriately added. 
A -Filter for state set constraints Is constructed 
In exactly the same fashion. The join must yield an empty 
Accessible RDS to satisfy the constraints. 
5.4.2. Content Constraints Alone 
Constraints which Involve only the content of the 


sensitive fleld are also easy to construct. Such 
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constraints do not involve logical "and"s, and the filters 
are therefore of order 1. Suppose, for example, that 
<religton> is the sensitive fleld, and the constraint Is of 
the form 


"if <religion> = Methodist | <religion> = Catholic, 
then access = M" 


The +Filter is then 
Religion 
Methodist 
Catholic 
The access handler joins this filter with the Requested RDS, 
and the rules for passing are the same as above; new 
constraints are formed by adding tuples. A -Filter would 
work similarly. 
54.3. Context Constraints Alone 
Context constraints alone are more difficult than 
either state set or content constraints because it cannot be 
guaranteed in advance that a filter applied to an arbitrary 
RDS will match on all flelds. This fact means that the '"*" 
cannot be used in the same fashion as In the above examples. 
Suppose that <salary> is the sensitive field, and 
that context constraints are to be specified. 
Simple context constraints are easily 
representable. If the constraint is of the form 


"Tf <<fieldname>> = social security number> then 
access = N" 


then the filter is 
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social curi n 


If the simple context constraint is a -Filter, the form is 
the same, but the rule is that the field must not match. 
Now suppose that the user wishes to express two 
constraints on the <salary> field, namely 
"if <soc. sec. no.> = 100-10-1000 then access = P" 
and (independent of that) 


"if <name> = <User_id> then access = P" 


One's first inclination might be to create the filter 


name SOC. SEC, NO: 
<user_id> * 
* 100-10-1000 


This filter, however, is inappropriate. By the rule that 
all fields must match, the first tuple specifies that both 
name and social security number must appear, and name = 
<user_id>; the second tuple is interpreted similarly. These 
are pot the constraints specified. Moreover, adopting a 
rule that only one (or more) fields must match would not 
solve the problem -- this filter would then pass any RDS of 
the form <soc. sec. no., salary>, due to the "*" jn the 
first tuple, and any RDS of the form <name, salary> due to 
the '"*" in the second tuple. 

Thus specifying "or™ constraints on separate 
fields of the context requires separate filters. Filters of 


more than one dimension have "and"s between the fields. 
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Only in the case of the state set may these "and"'s be 
ignored, 
5.4.4. Interactive Constraints Ane 

The interactive access handler is identical to the 
state set access handler, except that it uses an RDS of the 
form 


<User_id, Password> 


instead of the state set RDS. This RDS, called the Password 
Set, is also maintained by RSM_evaluated_functions_, and it 
contains the flagged RN's for <user_id>, and <password)>; 
therefore any reference to it causes calls to functions 
which obtain the user's name and a password from the 
console. 
Pure interactive constraints are of the form 
"if. <user_id> = Smith & <password> = openup, then 
access = PW 
and are represented in a +Filter RDS as 
r_id P d 
Smith openup 
Use of the interactive access handler is analogous to use of 
the state set access handler. 
5.4.5. Combinations of Constraints 
Combination of the various types of constraints is 
an extension of the filtering concepts presented above. The 


physical representation of compound constraints is 
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determined by the nature of the particular expression. In 
some cases more than one storage scheme for a given compound 
constraint is possible because of the three different 
representations of "and", In these instances the normal 
action should be to fit as many constraints as possible into 
one filter, in order to minimize both storage for ACL's and 
execution time for MARM. On the other hand, if a particular 
filter is sufficiently general that it may be shared between 
a number of different RDS's, one would not insert an "and" 
constraint if such an addition would render the filter 
unsharable. 

The above examples demonstrate that context 
constraints may be "and'ted into the same filter if the 
meaning of the constraint Is 

(<context constraint1l>) & (<context constraint2>). 
In the same fashion, a content constraint may be "and"ed 
Into a context filter. Thus if <salary> Is the sensitive 
fleld, the constraint 

one (<salary> = 10000) & (<group> = EE) then access = 
may be combined into one filter: 


10000 EE 


One might now "or" compound constraints into this filter 
(by adding tuples) only if they are of exactly the same form 


as the first; the filter cannot be used for <salary> 
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constraints alone, nor for <group> constraints alone. Note 
also that a +Filter and a -Filter could not be combined in 
this manner. 

In a similar fashion, certain state word 
constraints may be added to a centent/context filter, given 
that the RSM_evaluated_functions_ has been designated as the 
RSM for that filter. For example, if an existing filter for 


the <salary> field looked like 


Name Group 
Smith EE 


then we might specify that (in addition to passing <Smith, 
EE>'s salary) anyone from EE could see his own salary by 
adding the tuple: 

<<user_Iid>, EE> 


where <user_id> is the flagged RN for the current user's 
name. 

This exhausts the methods by which different types 
of constraints may be combined within a single filter. A 
pure content constraint could not be mixed In a filter with 
a pure state set constraint because the first requires a 
join with the Requested RDS, and the second requires a join 
with the state set. This is precisely the reason for the 
And_group construct of the ACL: for example, a compound 
constraint of the form 


if (<pure content constraint>) & (pure state word 
constraint>) then..." 
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is represented by separate filters whose corresponding 
tuples in the ACL are connected via the And group field. 
Any of the types of constraints may be "and"ed in an 
analogous fashion. The And_group may also be used to 
combine constraints which are representable in one filter, 
but this causes MARM more work. 

The highest level of logical "and"ing is the 
<fleldnumber> of the ACL control! RDS. This construct is 
provided primarily for MARM's convenience in computing ACL's 
for acquired RDS's, but could also be utilized by an 
originator of information who wished to share existing 
ACL's. 

In the interim system, the structure of the access 
control data base at and below the ACL_control RDS level 
will be largely under the control of the user who Is 
constructing it. It ts clearly possible for him to 
represent his constraints in an extremely inefficlent 
manner. To the extent that he wishes to specify simple 
restrictions, however, the complexity of the access control 


data can be minimized. 
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5.5. Standard Computation of Access Rights to Acquired 
Relation Sets 

It is claimed in Section & that the structure and 
philosophy of MADAM are such that the system must provide 
substantial aid in assigning access control data to derived 
sets. In fact, it should be possible to derive a set to 
which one has greater access privileges than he did to the 
input sets. 

The concept of filters and the MARM mechanisms 
presented in Section 5.4 provide the ability to determine 
whether or not a given RDS (and the current user's 
characteristics) satisfy the logical constraints specified 
by the ACL's. However, it is easy to demonstrate that the 
constructs presented there do not solve the problem of 
access control. 

5.5.1. What is Not Sufficient: Ihe Problem of Truth 

The problem of Truth may be demonstrated by a 
slight variation of the example of Section 3. Suppose that 
there exist two system data sets: 


<Name, Salary> 


and 

<Name, Group> 
both of which contain information about al} people 
associated with Project Mac. Let the restriction on the 


<salary> field be the same as before, namely, that the 


current user is allowed P access only to the salaries of 
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people also in Management. His access level to the two 
existing sets is M. 

There are (at least) two distinct ways that the 
user might derive a set containing only the salaries of 
Management people. He could create (by create_set and 


insert_tuple) either the set 


Nam Grou lar 

* Management * (1) 
or the set 

Name Group 

* Management (2) 


Using set (1), he could acquire the desired result by the 


sequence of operations 


(<Name, Group> join <Name, Salary>) intersect (1) 


The join yields an intermediate set <Name, Group, Salary> 


which contains data on everyone from the original sets, so 


the user should not have P access to it; the intersection. 


yields the set of Management personnel only. 
Alternatively, the user might perform the sequence 


(<Name, Group> intersect (2)) join <Name, Salary> 


In this case, the intersection gives the intermediate set 
<Name, Group> of all Management people, and the join appends 
their salaries by matching on the <Name> field. 

Either of these actions produces a set to which 


the user should have P access. The +Filter which represents 


the sensitivity constraint on <“salary> might look like 
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Group 
<group> 


where <group> is the flagged RN for the current user's 
group. If our user is indeed in Management, then this 
filter will pass the final acquired set. 

Suppose however, that the user. performed this 
operation: 


<Name, Salary> join (2) 


The join would match on the <Name> field, which in set (2) 
contains a "*"; the result would be the set 


<Name, Salary, Group> (3) 


which lists all the people from the original system data 
set, but in which the <group> field contains "Management" in 
every tuple. The filter shown above would pass this set as 
legitimate. 

This is the problem of Truth. Set (3) contains 
tuples which associate names with a group to which they do 
not belong. Although this is a simple example, the problem 
is not limited to the jotn operation; projection, 
composition, and product may also be used to alter the 
context of a sensitive field. Moreover, it fs possible to 
completely remove the sensitive field in such a fashion that 


its contents are still known to anyone who knows the series 


of operations used to derive the final result. 
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The example used here demonstrates that 
falsification may be performed itn one step; it is easy to 
conceive of much more subtle ways to do so under’ other 
conditions of sensitivity. It is possible to construct 
cases where falsification occurs without the use of the "x" 
convention anywhere in the derivation history. 

To take a further example, suppose our user wishes 
to obtain the salary of the Provost, who is associated with 
the group "Admin", and who lives in Cambridge. tn addition 
to the <Name, Salary> set and the <Name, Group> set, let the 
data base contain the following two sets: 

<Name, Town> 


(for everyone), and 


fe) T 
Management Cambridge 
Admin Cambridge 
(etc.) (etc.) 


where the last set contains the relation between groups and 
towns. Since people from different groups may live fn the 
Same town, some Data Elements may appear more than once in 
the <Town> field. In particular, at least one person’ from 
Management lives in Cambridge. If the user performs the 
following operation: 


(<Name, Town> join <Name, Salary>) join (<Town, Group>) 


then the final <Town, Name, Salary, Group> set will contain 


false information. The second join in the sequence matches 
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on the <Town> field, and will contain both the tuple 
<Cambridge, Provost, salary, Management> and the tuple 
<Cambridge, Provost, salary, Admin>, since Cambridge matches 
twice. The user could then intersect out the Management 
salaries from this (false) set, and obtain the Provost's 
salary. Clearly, identifying the point of falsification is 
not straightforward. 

The access control system must, therefore, know 
the derivation history of an acquired relation set in order 
to assign access rights, or it must know the Truth. It is 
not sufficient to have knowledge only of the state set 
variables and the content/context of the Requested RDS. 
Designing a system which knows the Truth is beyond the scope 
of the present work. 

5.5.2 Access Computation Rules 

Independent of the problem of Truth there are a 
number of cases in which access to an acquired set may be 
determined without resorting to the filtering technique of 
Section 5.4. 

The only method by which one may increase access 
is by subsetting away that information which he is not 
allowed to see. In the example of Section 3, access 


P when the non-Management personnel are 


increases from M to 
removed. If there are no context or content restrictions it 
is not possible to increase access in this fashion. The 


Restriction_flag in the KRDST indicates the presence of such 
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restrictions; if it is off, each field of the acquired RDS 
is assigned the minimum access level of the corresponding 
fields of the input. Thus if the only restriction is 


"Jones may not see salaries." 


then nothing Jones can do will allow him to increase his 
access rights to the <Salary> fleld. 

Moreover, the set operations unfon and product and 
the non-set primitive insert_tuple include all of the 
information of the input RDS's in the output RDS. The 
minimum access of the input flelds is again assigned. 

In the case of intersection and difference it is 
not necessary to know the Truth. These operations are 
defined only for inputs which have the same RD's, and 
therefore no use of "#" or "=--"' can produce false 
information in the output. Thus it is possible to increase 
access by subsetting if there are content/context 
restrictions on the inputs. In such cases, MARM evaluates 
the new ACL's of the acquired RDS in order to assign current 
access privileges. 

All of the remaining operations may falsify either 
content or context during the derfvation of the acquired 
RDS. Even removing the sensitive fleld completely by 
projection is insufficient. If the <Name, Salary> set is 


intersected with 


* 10000 
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and the <Salary> field of the result is projected away, the 
user still knows the salaries of the remaining names. 
Therefore, the minimum access. level aa the inputs is 
assigned for replace_tuple, projection, join, and 
composition. Moreover, MARM cannot guarantee the accuracy 
of an RDS which has one of these operations anywhere in its 
derivation history. Thus the False_content_flag and/or the 
False_context_flag are turned on In any RDS which is’ elther 
derived directly from one of these operations, or which is 
derived from inputs which have the flags. on. A set with 
either flag on not. only prohibits increasing: access, but 
also results in an acquired set which can never be used to 
increase access. 

This is the most severe shortcoming of the interim 
access control system; lack of knowledge about Truth places 
restrictions not only on the users of sensitive information, 
but also on the originators. In the example of Section 
5.5.1, the user could not acquire a set to which he has P 
access from the given system data base -- the join operation 
must be used at some point to establish the (true) <Name, 
Group> relationship. It therefore does not make sense in 
the interim system to place context restrictions on 
sensitive information unless that context appears in the 
basic data _ set. Moreover the interim system will in some 
cases over-classify an acquired RDS; information which 


should be released will not be released. 
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In summary, the interim rules for assigning access 
privileges to an acquired RDS are: 


1) If there are no content/context restrictions 
on the inputs, or if the operation is anything other 
than intersection or difference, or if either of the 
inputs have the False_content_flag or 
False_context_flag on, then the access to each field is 
the minimum of the access levels to the input fields. 


2) Otherwise, evaluate the new ACL's to determine 
the access rights. 
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5.6. Non-Standard Access Handling 


It ts the aim of the access control system to 
support access control at a level sufficient to handle the 
needs of the great majority of users. However, the system 
is not closed; a user who wishes’ to have special 
restrictions on his data can do so. The only. constraint 
which the interim system places on users is that assigned 
access privilege levels must be members of the set of 
capabilities of Section 5.2.1. 

Since the construction of the ACL's for an RDS is 
under the control of the originator of sensitive 
information, either he or anyone to whom he has granted the 
capability to change access information may place an 
arbitrary program (or programs) on the ACL. The 
<Access_handler> field of the ACL will normally contain the 
name of a system-supplied program which tests constraints of 
the form described in Section 5.4. In these cases, the 
<Data_rds> field will point either to a filter RDS or to the 
State Set or Password Set. However, the access handler may 
be a user-supplied program. In this case, the <Data_rds> 
field of the tuple may, of course, point to any data _ in 
MADAM format. 

However, other users must be protected from the 
results of such’ programs. In the current Multics 
implementation a program called from a more privileged ring 


acquires the privileges of the caller; any program called 
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by MARM will have MARM's privileges. ft will therefore he 
necessary for a user who wishes to use his own access 


handlers to submit them for approval by system supervisors. 
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6. EVALUATION OF THE INTERIM ACCESS CONTROL SYSTEM 


This section summarizes both the good and bad 
points of the interim access control system. 
6.1. Generality and Compatibility 

Perhaps the most powerful feature of the interim 
system is its ability to represent access control 
information which is specifled as a series of general 
logical constraints on the system state, the content of the 
sensitive field, and the context In which the sensitive 
Information appears. The ortginator of information Is no 
longer reduced to supply Ing an exhaustive list of the names 
of persons who can access his data; he can now make 
statements Ike 


"Anyone can see his own salary." 


Through use of logical "and", "or", and “aot; the 
originator may concisely specify complex conditions for the 
release of his information. 

This powerful representation of constraints is 
supported by a very. general definition of the term "user 
identification" -- the state set supplies an extensive list 


of characteristics of the user which may be accessed for 
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many purposes. In addition, the fine distinction of the 
term "access" greatly extends the types of access that may 
be assigned. 

Power is also provided by the separation of the 
concepts of the “owner" of information, the "originator" of 
information, and the person (or persons) who may change the 
access control restrictions. It is possible to give someone 
a physical copy of sensitive infermation and allow him to 
manipulate it while denying him the ability to pass the 
information along to another user. 

The interim access control data base is compatible 
with the rest of MADAM data storage, with the exception of 
the <And_group> field of the ACL and the <fieldname> flteld 
of the ACL_control RDS, both of which require special 
handling. For the "pure" RDS's in the access control data 
base, all the MADAM operations are applicable; even in the 
case of these two impure sets, the non-set primitives 
provide powerful manipulative tools. Moreover, the interim 
system uses only MADAM operators to make its access control 
decisions, except for manipulations involving these two 
fields. 

6.2. ibi 

The interim system may be readily extended along 
both the second and third dimensions of access control. 

The division of "access capability" into P, M, S, 


N, etc. is an arbitrary program restriction, and might be 
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made either more or less coarse as experience dictates. The 
access handlers are completely independent of this division; 
a little cleverness in the programming of the MARM module 
itself will make such changes very easy to make. One 
conceivable extension, for example, would be an expansion of 
the € capability. In the interim system a user may change 
all of the access control information for an ROS, or he may 
change none. However, the access control data base itself 
is Just a series of RDS's which are protected by exactly the 
same mechanisms as any other RDS; subdividing the Cc 
capability would amount to assigning their access rights 
individually rather than collectively. 

In addition, the use of the RSM for evaluated 
functions means that extension of the system to include more 
knowledge about the environment is a trivial matter -- since 
the state set is a pure RDS, and since the only interactions 
with it are through standard set operations, adding a_ field 
presents no problems. 

Lastly, the fact that the access handlers may 
themselves be arbitrary programs provides a convenient 
escape for special conditions, as well as a short-term 
solution to some cof the limitations of the interim system. 
6.3. Limitations 

Clearly the most important limitation of the 
interim access control system is fits inability to know the 


Truth. On this account, its performance in assigning access 
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privileges to new RDS's is severely impaired. All of the 
operations which may be used to falsify content or context 
may also be used in quite legitimate ways for obtaining 
information which the user should be allowed to see, but 
which the interim system will not release. 

The second limitation of the interim system is the 
complexity of the MADAM representation of access control 
restrictions in the ACL data bases. Expression of arbitrary 
Nand"s, “ors, and "not"s may well result in a large number 
of small RDS's which express the access control data for a 
single RDS. However, given the current configuration of 
MADAM, the representation presented here fs the simplest 
possible. 

A subproblem of the representation of logical 
constraints which further limits the access control system's 
operational power is the use of the <And_group> and 
<fieldnumber> constructs, which make their respective RDS's 
impure and therefore not subject to manipulation by set 
primitives. This limitation, however, is transparent to the 
user; it affects only the amount of special programming 
within MARM itself. 

From the user's viewpoint a more noticable 
limitation is the fact that only current MADAM operators may 
be used in expressing constraints; constraints involving 
arithmetic operators therefore presently require special 


purpose programming. This restriction applies throughout 
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MADAM, however, and is not limited to access control. 

The tnterim system's position along the dimenston 
of physical level of control Is relatively fixed: a 
decision to protect information at any level other than’ the 
field level within RDS's would be much more difficult to 
implement than a change in assignable access capabilities. 
However, such a change would affect only the MARM module 
itself. Moreover, the interim system allows one to protect 
soecltic fields of specific tuples; it Is difficult to 
imagine an application for which this level of control would 
be insufficient. 

The last important limitation of the InterlIm 
scheme is the fact that user-supplied access handlers must 
be submitted for approval before they may be used. This” 
restriction results from the current MultIics limitation that 
a procedure called from an inner ring has all the privileges 


of the calling program. Multics is considering eliminating 


this restriction. 
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7. SUGGESTIONS FOR FURTHER STUDY 


This thesis has clearly tdentified at least as 
many problems as it has solved: 

First there is the problem of Truth. In a data 
management system which provides non-trivial mechanisms for 
manipulating information it is possible to construct false 
information in extremely subtle ways. This problem is by no 
means limited to the realm of access control -- it must be 
solved before MacAIMS can support a user interface which 
does more than map single commands’ into single set 
operations. Indeed, the problem affects users even if they 
specify set operations one-by-one; falsification might 
occur almost as easily by accident as by design. 

Second, there is the problem of interfacing 
general logical expressions with the existing MADAM 
structure. In the access control system, this is evidenced 
by the complexity of the data structure which results from 
forcing logical expressions into a data format which is 11] 
suited for their representation. This problem also 
transcends access control. The addition of boolean 
operators to MADAM merits investigation in its own right. 


The need has also been shown for the addition of 
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arithmetic operators to the set of tools which MADAM 
supports. Such an addition is clearly desirable in 
providing power to the user. 

These issues all exist separately from the problem 
of access control, though their solutions would greatly 
enhance the access control system's capabilities. In 
addition there are two problems concerning access control 
alone which should be examined: 

First there is the question of results of 
computations which are final from the access control system 
viewpoint, but which the user views as interim results for a 
computation which takes place outside the computer. The 
access control scheme cannot know if a user takes two 
printouts from different operations (or different login 
sessions) and intersects them in his head. The fact that 
access rights are assigned at each interim step in a 
computation provides a powerful tool for solving this 
problem, but the responsibility for appropriate 
specification of constraints currently rests with the 
originator of sensitive information. A better understanding 
of the problem of partial results would help guide users in 
setting up thelr sensitivity specifications. 

Lastly, there is the problem of conflicts of 
privacy. The interim system orovides for only. one 
criginator of information, along with the capabilities which 


"originator" implies; it would be fairly easy to extend 
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these concepts to include multiple originators of 
information who would have to collectively agree to its use 
cr dissemination. While such a simple idea would be a large 
step in the right direction, a much better theoretical 


understanding of conflicts of privacy is needed, 
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8. CONCLUSION 


This thesis has not been a_ dissertation on 
privacy; it presents the design of an access control 
subsystem for a particular data management system. The 
preceding pages not only demonstrate that no system in 
common use today provides a working environment in which 
users may conveniently protect the rights of others; they 
also show that furnishing that environment is not (and will 
not be) an easy task. The MacAIMS access control system is 
complex in structure; it will probably be costly to use. 
Moreover, it is not the whole solution to the access control 
problem. 

But even establishing the environment is not 
enough. The MacAIMS interim access control system has no 
morals; it protects no one's privacy. We do not. provide 
control; we provide the ability to control. 

Data processing has no social value in its own 
right: it is a means to meet other ends. Yet the drive to 
collect data is extremely powerful in [ftself; left alone, 
it often becomes the goal rather than the means. The morals 
of privacy cannot be built into the hardware -- they must be 


built into the users, the programmers, the system 
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administrators. 


Today our ability to collect, process, and 
disseminate information far outweighs our knowledge of what 
to collect, how to process it, and when to disseminate it. 


The time to close that gap must be now. 


10. 


ll. 
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